A variety of programs on the market allow a developer (e.g., a web developer) to create web pages, websites, interactive applications, and the like for use by end users (e.g., visitors to websites). Examples of such programs include DREAMWEAVER™ and FLEX BUILDER™, each available from MACROMEDIA INC., of San Francisco, Calif.
DREAMWEAVER™ is an Integrated Development Environment (IDE) that allows web developers to design Hypertext Markup Language (HTML) web pages in a code editor and also in a graphical-based design time environment. In other words, DREAMWEAVER™ parses tags (e.g., HTML tags) and renders an interactive simulation of the application in the design time environment. Thus, a user may edit the application by directly editing the tags or by graphically manipulating the design time representation. As the user graphically manipulates the design time representation, the program changes the tags to reflect the modification. DREAMWEAVER™ also allows the developer to design with more than just HTML, such as, for example, the developer may use Active Server Page (ASP) and C# from Microsoft Corporation, COLDFUSION™ Markup Language (CFML™) from MACROMEDIA INC., and the like. Examples of other HTML IDEs include GOLIVE™, available from Adobe Systems Incorporated, and FRONTPAGE™, available from Microsoft Corporation.
FLEX BUILDER™ is an IDE for creating Rich Internet Applications (RIAs), which are interactive, multimedia applications, that may run on client-side players, for example, MACROMEDIA INC.'s FLASH™ player. MXML™ is the native tag-based language for FLEX BUILDER™, while ACTIONSCRIPT™ is a script-based procedural language for FLASH™-based RIAs. In developing RIAs using FLEX BUILDER™, a developer may write MXML™ tags and ACTIONSCRIPT™ code and save it in an MXML™ file to the FLEX™ server, which is a presentation level server for RIAs. The FLEX™ server includes a compiler that compiles the MXML™ and ACTIONSCRIPT™ into ACTIONSCRIPT™ bytecodes. The FLEX™ server saves the ACTIONSCRIPT™ bytecodes in a file, such as a Small Web Format (SWF) file, that can be downloaded and executed on a user's machine. SWF is the native file format for the FLASH™ player.
Web sites, RIAs, and other applications generally include one or more visual components, which are application elements that have a visual appearance on an end user's screen. Visual components may include text paragraphs, pictures, and the like. Visual components may also include form controls, such as check boxes, data grids, radio buttons, and the like.
When a developer is creating a visual component, such as by defining a new form control, the developer typically works with three conceptually different pieces. First, there is the logic function of the visual component. The logic function may, for example, direct that a data grid scrolls down to show the next row when an end user selects a button on a scroll bar. The logic function, therefore, controls or defines the performance of some kind of event. The second piece is the appearance of each separate part of the component. This includes different visual assets, such as an icon that appears on a button, the thickness of a border around the edge, the various colors, and the like. The third piece is the organization of the visual assets relative to one another to produce the layout of the visual component. The third piece includes, for example, the position of a scroll bar button above a scroll bar track, the position of a second button below the scroll bar track, a border along the outside of a data grid, and the like.
Traditionally, application development groups have relied on developers (i.e., programmers) to provide all three of those pieces—writing code for the logic, using code to create functions to draw the individual visual assets, and using code to position the visual assets in the visual component.
Relying solely on code to create an application usually means that an artist/designer cannot directly change the appearance of visual assets because artists/designers are typically not programmers. The appearance of the visual component often reflects the artistic talent involved in its creation. Thus, a disadvantage of having developers, rather than artists/designers, directly involved with all three of those pieces is that there is a limit to how expressive and artistic the application can be. The traditional process is for an artist/designer to mock up the appearance of the application and then give it to a programmer who approximates the appearance in the application. However, the programmer may, for example, fail to arrange the visual assets in a pleasing way, which is often a subtle task. The process then goes back to the artist/designer, who provides input to the programmer to make changes. Application development can, therefore, be a frustrating, iterative experience when artists/designers are not able to directly affect the appearance of the application.
TRILLIAN™, an Instant Messenger (IM) client from Cerulean Studios of Connecticut, is an example of an application that allows artwork to be positioned using a tag-based language. WINAMP™, a digital music player from Nullsoft of Sedona, Ariz., is another example of such an application. However, neither TRILLIAN™ nor WINAMP™ allows a programmer to contribute to the artwork using a script-based language. Accordingly, there is no available technology that allows both artists/designers and programmers/developers to directly affect the artwork of an application.